開始之前，先寫下三條驗收條件。今天的版本是：
沒有驗收條件的迭代，說到底只是重複生成。
前幾天累積下來的日誌是按日期排列的。這種寫法適合記錄每天做了什麼，卻不容易回答另一類問題：某項技術第一次在哪裡出現、後來查到了什麼、哪些判斷還沒有證據，以及下一次應該從哪裡接著做。
所以今天不只整理 Day 1 到 Day 5，也不打算再做一份讀完就放著的摘要。這一輪要從既有日誌抽出技術、問題、決策、限制與下一步，在 Confluence 個人空間裡另建一個「個人工作脈絡」區塊。
日誌繼續保留時間順序，工作脈絡則整理項目之間的關係。基本框架建好後，再接上 Microsoft Learn MCP 等官方來源，補進已確認的能力、限制與相依條件，最後把查證結果轉成下一步可以執行的方案。
原本拆成四站，實際跑過一次後，發現同一天要處理的內容太多。這次收成三站：
頁面名稱、日期範圍、工作目標與限制都可以換成自己的內容。
請讀取 Confluence 個人 Space 裡「iThome 鐵人賽 AI 自動化研究日誌」底下 Day 1 到 Day 5 的頁面。
這一輪要根據既有日誌，在同一個個人 Space 中建立一個獨立區塊「AI 自動化個人工作脈絡」。
只從日誌內容整理，不要查外部資料，也不要補充你自己知道的東西。
請從日誌抽出以下五類內容：
一、出現過的系統、產品、服務與技術名詞
二、每一頁的問題與「待驗證事項」
三、已經做出的決定，以及決定成立的前提
四、頁面裡提到的限制、風險與尚未確認的假設
五、每一頁的「明日規劃」、下一步行動與預計產出
每一個項目都要保留：
- 項目名稱
- 項目類型
- 日誌中的原始描述
- 來源頁面名稱
- 來源頁面 URL
- 頁面內記載的建立日期
- 目前狀態：已確認、待驗證、進行中、已完成或無法判定
整理完成後，在「AI 自動化個人工作脈絡」底下建立以下頁面：
1. 工作脈絡總覽
2. 技術與服務索引
3. 問題與待驗證事項
4. 決策、限制與前提
5. 實驗與下一步
規則：
- 如果「AI 自動化個人工作脈絡」不存在，就新增這個區塊。
- 如果已經存在，沿用原有區塊，不要建立名稱相同的重複頁面。
- 同一個項目出現在多篇日誌時，合併成一個項目，但保留全部來源。
- 名稱相近但無法確認是不是同一個項目時，不要自行合併，標示「待確認是否為同一項目」。
- 如果你開始解釋任何技術名詞，那是越線。這一站只建立索引與關係，不解釋。
- 如果頁面裡的建立日期是空白，標示「頁面內未記載」，不要自行推算。
- 找不到來源頁面 URL 的項目不要放進正式索引，另外列在「無法建立來源連結」清單。
- 不要修改、移動、重新命名或刪除原始日誌及 Day 1 到 Day 5 的任何內容。
寫入前，先列出預計新增或更新的頁面。確認操作範圍只在「AI 自動化個人工作脈絡」之後，再開始建立頁面。
完成後回報：
1. 讀取了哪些日誌頁面
2. 新增或更新了哪些工作脈絡頁面
3. 抽出了多少個技術與服務項目
4. 有多少個待驗證事項
5. 哪些項目缺少日期、來源連結或明確狀態
原本的第一站只會輸出幾份清單。這一版多做了一件事：把清單放進一個獨立的 Confluence 區塊，成為後續可以持續更新的骨架。
日誌和工作脈絡從這裡開始分工。
日誌保留「那一天做了什麼」；工作脈絡整理「這件事目前知道多少」。同一項技術可能在 Day 1 被提出、Day 3 加入限制、Day 5 才變成實驗題目。它在日誌裡分散在三頁，在工作脈絡裡則會合併成一個項目，並保留三個來源連結。
這一站已經有 Confluence 寫入權限，所以 Prompt 裡先限定頁面結構，再明確禁止修改原始日誌。它能新增工作脈絡，但不能順手替我重寫過去五天的內容。
第一站完成後得到的還不是知識庫。它比較像一個剛搭好的書架：技術、問題、限制與下一步已經各自有位置，但架上的內容仍然只來自自己的工作紀錄。
請讀取 Confluence「AI 自動化個人工作脈絡」底下的：
- 技術與服務索引
- 問題與待驗證事項
- 決策、限制與前提
針對其中狀態為「待驗證」或「無法判定」的項目，使用 Microsoft Learn MCP 查找官方資料。
如果項目涉及 MCP 規格，可以同時查詢 modelcontextprotocol.io 的官方文件。
這一站只做查證與擴充，不要修改 Confluence 頁面。
每一個項目給我以下內容：
1. 日誌中的項目名稱
2. 日誌原本怎麼描述
3. 官方文件使用的對應名稱
4. 官方怎麼說：保留一到兩句能直接回答問題的原文
5. 官方頁面 URL
6. 官方文件提到的成立條件或限制
7. 這項資料與目前工作脈絡的關係
8. 往下牽出的兩個相關概念
9. 驗證狀態：已找到、部分找到或找不到
10. 尚未回答的問題
來源標記規則：
- 來自日誌的內容標記「內部日誌」，並附原始日誌頁面 URL。
- 官方頁面直接記載的內容標記「官方文件」，並附官方頁面 URL。
- 根據日誌與官方資料之間的關係做出的判斷，標記「你自己的推論」。
- 官方文件沒有直接回答時，寫「找不到」。
- 「部分找到」必須說明找到哪一部分、缺少哪一部分。
- 不要把搜尋結果摘要當成證據。
- 不要把產品介紹或宣傳文字改寫成已經驗證的能力。
- 每一條官方說法後面都要緊接來源 URL。
最後用樹狀結構輸出：
根：
建立可連續閱讀的 iThome 鐵人賽 AI 自動化主線，釐清 Agent、Workflow、RAG、MCP 與 Copilot Studio 的角色邊界，並以企業 IT 服務台為案例，評估知識檢索、工具呼叫、人工確認與流程執行的可行性。
幹：
從工作脈絡中抽出的問題、技術、服務與待驗證事項。
枝：
官方文件確認的能力、限制、相依條件與適用範圍。
葉：
查到的官方說法，每一片都要帶來源 URL。
找不到官方依據的項目不要硬接葉子，統一放在「待自行實驗」分支。
這一版不再手動把七條待驗證事項貼進 Prompt。第一站已經把它們放進「問題與待驗證事項」，第二站直接讀工作脈絡裡的最新版本。
以後多寫一天日誌，只要增量更新第一站建立的索引，新出現的問題就會進入同一個脈絡。第二站查的也不再是某一天留下來的固定清單，而是目前仍未確認的項目。
第二站查到的內容分成三層。
第一層是日誌裡原本寫了什麼；第二層是官方文件明確說了什麼；第三層是兩者接起來之後產生的推論。這三層不能混在一起，否則過幾天再回來看，很容易把當時的猜測記成產品本身的能力。
「找不到」也不代表這次查詢失敗。有些問題本來就不會出現在官方文件裡，例如某種組合能不能重現自己的案例，或固定題組應該怎麼設計。這類項目應該從「查文件」轉到「做實驗」，而不是再生成一段更像答案的文字。
以下資料來自 Confluence 的「AI 自動化個人工作脈絡」：
<核心目標>
請讀取「工作脈絡總覽」中的目前目標。
</核心目標>
<知識樹>
請使用第二站輸出的完整知識樹。
</知識樹>
<限制與前提>
請讀取「決策、限制與前提」中的相關內容。
</限制與前提>
<下一步>
準備模擬文件、資產清單、工單端點與固定測試題，完成企業 IT 服務台最小版本。
</下一步>
先針對這個下一步提出三條互相排斥的實作路徑。
「互相排斥」是指三條路採用不同的主要技術邊界或流程控制方式。實作第一版時必須選擇其中一條作為主路徑，不能只是同一套架構的簡單版、標準版與進階版。
每一條路都要寫：
- 路徑名稱
- 核心做法
- 哪個元件負責知識檢索
- 哪個元件負責工具呼叫
- 哪個元件負責流程控制與人工核准
- 哪些元件明確不放進第一版
- 成立條件
- 能驗證與無法驗證的事項
- 代價與主要風險
- 目前還缺的資訊
- 最小可行實驗
- 通過條件
- 停止條件
每一個論點後面標記來源：
- 「官方文件」：官方頁面直接支持，並附 URL。
- 「內部日誌」：來自工作脈絡中的原始日誌，並附頁面 URL。
- 「你自己的推論」：由現有資料推導，但尚未被來源直接證實。
- 「找不到」：目前沒有足夠資料支持。
用比較表確認三條路在主要架構、知識來源、工具介面、流程控制方式、人工核准位置與第一版範圍上確實互相排斥。
不要直接替我決定最後方案，只指出：
1. 哪一條最適合先降低未知風險
2. 哪一條最接近日誌目前的方向
3. 哪一條包含最多「你自己的推論」
4. 正式決定前還需要完成哪些實驗
完成方案比較後，把本輪結果寫回「AI 自動化個人工作脈絡」。
更新以下頁面：
一、「技術與服務索引」
補上已查證項目的官方名稱、官方說法、成立條件、限制、來源 URL 與驗證狀態。
二、「問題與待驗證事項」
更新每一條問題的狀態。
沒有官方答案的項目不要刪除，改標記為「待自行實驗」。
三、「決策、限制與前提」
加入本輪確認的限制、適用條件與仍未證實的推論。
四、「實驗與下一步」
加入三條互斥方案、最小可行實驗、通過條件與停止條件。
另外新增一頁「本週工作脈絡擴充紀錄」，依序保存：
1. 建立日期與驗證日期
2. 本輪讀取的日誌範圍
3. 本輪使用的官方來源
4. 第二站產生的完整知識樹
5. 三條互斥方案
6. 「找不到」清單
7. 「你自己的推論」清單
8. 下一輪應優先驗證的項目
寫入規則：
- 保留原始日誌來源 URL。
- 保留所有官方頁面 URL。
- 保留每一個論點的來源標記。
- 不要把「你自己的推論」改寫成既定事實。
- 不要刪除尚未驗證的問題。
- 同一項目已經存在時，補充驗證結果，不要建立重複條目。
- 如果新資料與舊紀錄衝突，保留兩者並標記「待釐清」。
- 不要修改、移動、重新命名或刪除原始日誌、週總覽及 Day 1 到 Day 5 的任何內容。
- 不要修改工作脈絡中與本輪無關的項目。
完成後回報：
1. 新增或更新了哪些頁面
2. 找到幾條官方依據
3. 有幾項「找不到」
4. 有幾處「你自己的推論」
5. 有幾項已轉成「待自行實驗」
6. 下一輪應先處理哪些項目
第三站把原本分開的「方案評估」和「寫回日誌」合在一起。理由很簡單：方案如果沒有寫回工作脈絡，下次開始時仍然得重新整理；但如果為了寫回再切一站，今天的操作量又會太大。
這一站仍然分成前後兩段。前半段先產生互斥方案，後半段才更新 Confluence。查到的事實、尚未證實的推論，以及只能靠實驗回答的問題，都會回到第一站建立的位置。
互斥方案也不是把同一套架構分成入門版、標準版和完整版。例如其中一條可以由 Copilot Studio 內建能力負責主要流程；另一條把檢索與工具介面放到自建服務；第三條則以 MCP 作為主要工具邊界。選擇其中一條時，第一版就要明確放棄另外兩條的核心做法。
看輸出時，先數「你自己的推論」出現幾次，再看「找不到」最後被轉成多少個實驗。前者表示方案裡還有多少地方站在猜測上，後者則決定下一輪要實際動手驗證什麼。
拿自己的日誌先寫三條驗收條件，再走完這三站。
第一站不用追求完整，先讓日誌裡反覆出現的技術、服務、問題、決策與限制，各自有一個固定位置。只要來源留得住，同一個項目之後還能繼續補。
第二站再接 Microsoft Learn MCP、官方文件搜尋或其他可信來源。每次只擴充一小批尚未確認的項目，不需要在一天內把整個領域查完。
第三站挑一個真的準備動手的下一步，提出互斥方案，然後把查證結果、未知項目與實驗條件一起寫回去。
走完後回頭看三個數字：
第一個數字代表工作脈絡能不能回到原始現場；第二個數字決定接下來要做哪些實驗；第三個數字顯示目前的方案有多少部分還只是推測。
前六天留下的是按時間排列的工作紀錄。第七天開始，這些紀錄被重新掛到同一張脈絡裡。往後新增的日誌不只會成為下一篇文章的素材，也會更新既有的技術索引、問題、決策與實驗。
下一輪再開始時，讀到的不只是「昨天做了什麼」，還包括這件事從哪裡開始、已經查到哪裡，以及哪一段仍然沒有證據。
日誌保存走過的路，工作脈絡保存下一步從哪裡開始。
iThome鐵人賽
看影片追技術